VI.FUME
23 FUME FHIR Function($resolve, $search, $literal)

今天要講的可能是FUME裡面最核心也最好用的部分了，就是FHIR Functions，
對應到FUME documentation的FHIR Functions那邊，

前面我們有使用過HAPI FHIR的GUI介面與POSTMan來與HAPI FHIR溝通，
那FUME有沒有辦法與FHIR Server溝通呢，答案是有，但有部分限制。

首先，就如同前面所提到的，FUME與FHIR Server溝通必須要先讓FUME以Stateful開啟，並且能正確的讀取到FHIR Server的資訊，

在這些事情都完成，確定FUME是Stateful後，我們可以開始今天的主題了。

今天的主題會高度扣合前面討論過的FHIR Search，如果不太熟的讀者可以回去看一下。

$resourceId() / $literal()

這兩個我放在一起講，他們的用法都是一樣的：$resourceId(query)

#INPUT
"primary_doctor": {
	"full_name": "Dr. Dolittle",
	"license": "1-820958"
}

#FUME
* reference = $literal('Practitioner', {'identifier': primary_doctor.license})

#FHIR
"reference": "Practitioner/fume-example-doctor"

這個function是用來標註reference使用的，他可以返回搜索得到的指定id，
當然其實這個function也可以靠後面的幾個function來達成。

$resolve()

這個function其實我們在剛開始介紹FUME的時候就有出現過了，那個時候是拿來匯出StructureMap用來給FUME Engine去使用，
但事實上這個function有幾個特性：

1.無限制域，只要是http能到的FHIR Server，權限允許的情況下都能存取
如"https://hapi.fhir.tw/fhir/Patient/ResourceID"

2.一次單筆Resource
這邊要注意一下，有讀者可能想說單筆沒關係啊，我$resolve一個Bundle就好了，反正Bundle也是單個Resource，只是下轄非常多entry
有這個想法很好，只是很可惜的是作者在原始碼的部分把它封掉了，因此$resolve不能query一個Bundle，

3.如果前方沒加上FHIR Server的前綴，預設會去Query與FUME連動的目標FHIR Server Resource

#FUME
$resolve("https://hapi.fhir.tw/fhir/Patient/77")

筆者目前無法得知是什麼理由要封掉Bundle Query，因為等等會提到$search與$resolve的差異。

$search()

這個function跟$resolve其實非常相似，差別的地方有兩點：

1.限制域，$search只能搜索連動的FHIR Server上的Resource，雖然可以搜索Bundle並得到Resource內容，但畢竟不是遠方的資料

2.可複數筆資料的搜索
如果搜索的條件僅找到單筆Resource，以該Resource的ResourceType呈現；如果找到多筆Resource，
$search返回的是一個SearchSet Bundle，其實這個機制就跟HAPI FHIR在被搜索的行為一模一樣，

#FUME
$values := $search("StructureMap?_sort=-_lastUpdated&_count=" & $cnt).entry.resource.id;

在實作面上，只需要將Bundle.entry抽取出來，就能夠針對內部的Resource去做組裝。

這邊的括號內query參數都是直接相容於FHIR Search的參數，也就是說，

要將FHIR Server間撈取資料的實作做的好，必須要詳讀FHIR Search提供的說明。

這邊想特別講一下$resolve的潛力在哪裡，

如果能夠遠程存取FHIR Resource，這就意味著：

#FUME
$resolve("https://nhicore.nhi.gov.tw/pas/CodeSystem/organization-identifier-tw")

FUME能夠讀取某個CodeSystem或是ValueSet，

當使用者填入某個CodeSystem的code時，FUME就可以自己去尋找這個code是否屬於哪個CodeSystem? 這個code是否有效

能非常輕易的完成普遍實作中最麻煩的值集對應問題。

當然這只是一個小範例，當解鎖了FHIR Server間的Resource存取，能夠玩的花樣就會多很多了。

今天的內容比較少一點，但是這幾個功能使FUME變得能夠從Infra角度來執行FHIR的每個轉換，甚至是組裝。

當然，這一切的前提還是得建立在FHIR Server是連動可用的狀態，實務角度上還需要考慮FHIR Server的安全性，

因此$resolve並不總是能存取一個遠方FHIR Server的值集，筆者目前測試hl7的valueSet、大型編碼系統如loinc等就並不一定能穩妥使用，

僅供IG自定義的值集內容存取比較適當，

當然的，這樣子的實作好處也帶來了一定程度的犧牲，
儘管搜尋值集的內容與代碼對應非常方便，可是在每次執行轉換有使用到該搜索時，因為搜尋的是遠方的Resource，
勢必會有http連線所需要的時間，一來一回之下就會增加不少轉換時間，比較需要注意的是，

FUME在轉換FHIR Resource時是可以套用快取的，初次轉換在沒有快取的情況下會比較久，但同樣的FUME Mapping在之後的轉換中
由於可以讀取已編譯完成的快取，轉換作業可以在瞬間完成，

然而，由於搜尋是外部存取，無法被快取使用，所以無論這個FUME Mapping是否有經過快取編譯，在拿到遠方的Resource所要花費的時間是不會減少的
這意味著少量使用是沒問題的，但遇到內容異常龐大的值集(如loinc)，光讓FUME執行搜尋就可能佔掉超過一半以上的轉換時間了，

要怎麼取捨來自於實作者的考量，以筆者的角度來說僅推薦處理範圍小，但又沒有小到可以以JSONata物件處理的值集，

這個技術還有另一個很好用的場合就是處理coding中的code與display關係，

在最前面提到的，FHIR格式是一個能夠讓人與電腦都同時看懂的東西，電腦看code，人類看display內的字串，
但如果我們將code與display同時提供於輸入非常沒有效率，也沒有讓使用者的輸入減少，所以$resolve就很適合擔綱這個任務

大致上把FUME能夠使用的基本操作都講完了，
明天來講概念類的東西，既然都已經了解這些操作了之後，我們該如何利用這些功能來組出來一個程式化的FUME Mapping，

真正的讓FUME的轉換變得靈活。